SmartDataObject basics
The Progress Dynamics framework is, to a large degree, based on the use of SmartObjects, and of the Application Development Model 2 (ADM2), to define components, their properties, and their behavior. This guide does not attempt to replace other product documentation on SmartObjects and the ADM2, but it attempts to provide enough background so that if you are not already familiar with the ADM2, you can still get a serious start developing Progress Dynamics applications.
The dynamic SmartDataObject (SDO) is in many ways the heart of a Progress Dynamics application. It is a Progress 4GL procedure that defines a database query for a table, or for a join between multiple tables, and a list of fields from those tables to present to the user. It defines a temp-table (named RowObject) with that field list. It is designed to operate transparently in a distributed environment, as are all the other components of Progress Dynamics. To do this, each SDO can run in an AppServer session on a server machine where the Progress Dynamics Repository database and/or the application databases are located. The SDO loads data as requested into its temp-table and sends that temp-table over to a client session th, in principle, runs without any direct database connection of its own. Designing for client sessions without a database connection prepares you for deploying your application with the Progress WebClient. This means that user sites, which can be anywhere in the world, do not need a preinstalled Progress run-time session connected to a central server or servers where the databases and the supporting application business logic are installed.
Each client session runs what is called a proxy version of the SDO. This proxy version has the same temp-table definition. It can receive data from the server, make it available to other objects (such as browsers and viewers) in the client session, collect updates, and pass them back to the server. Progress Dynamics handles the connection between client and server objects internally. If you have defined the logical name of the application Service for your SDOs and properly configured it in the framework (as described in later chapters), the framework will properly initialize your SDOs and other objects. The objects will communicate with each other so that data is made available on the client efficiently and automatically.
Note: Progress Dynamics supports both static and dynamic SDOs, SBOs, browsers, and viewers. However, most of the material in this manual assumes you are working with dynamic objects since they are the natural domain of the framework. For clarity, when speaking of only dynamic objects, the dynamics class name can be used as a shorthand. For example, the class name for dynamic SDOs is DynSDO.Figure 5–1 shows the basic interaction between the server DynSDO and the client proxy DynSDO.
Data is loaded from the database into the RowObject temp-table on the server and sent to the equivalent temp-table in the client. Data from the temp-table is displayed in browsers and viewers. You can update records in a viewer (or sometimes in a browser). Any updates go into a similar temp-table, called RowObjUpd, containing only updated and added records; these are sent back to the server. Validation logic to assure that all changes are correct is normally executed on the server so that the application database will be available for lookups and updates of related records. Validated changes are written back to the database in the server session. Again, all required server-side objects are started automatically as needed. The client session acts, in effect, as if all the data were available locally. In f, the same application could run entirely on the client, with a local database connection or a direct client/server database connection, simply by configuring it that way, and everything would work exactly the same.
SDO data logic procedure
The SDO gets data back and forth from client to server properly without any coding at all on the developer’s part. But updates to that data almost always require some degree of validation, and perhaps the execution of other business logic to update related tables or to do whatever else is required. This business logic is the essence of your application.
The SDO is designed to make it as easy as possible for you to define at least the first level of business logic, that which applies to updates to a specific table, within the SDO, so that table validation will be executed reliably whenever changes occur to the data in that table.
Later chapters discuss the details of defining business logic in your application. So that you can use the Object Generator and understand what it creates for you, this section covers some of the basics.
The Object Generator can, in a completely automated way, create a dynamic SDO for a set of fields in a table that handles all the basic operations for you. A major accomplishment for SmartDataObjects in Progress Dynamics is that they have been made fully dynamic objects, like most other framework components. This means that the individual source procedures have simply disappeared and have been replaced by data in the Progress Dynamics Repository that describes everything the application needs to know about the object: its query, its field list, its Application Service logical name, and so forth. A single “dynamic SDO” procedure is able to read the data for any SDO and create the query, temp-table, and other constructs at run time.
The Object Generator writes all business logic relating to the SDO to a separate source procedure. This Data Logic Procedure becomes a super procedure of the SDO at run time, so all the internal procedures it contains effectively become part of the SDO when it executes. The Object Generator creates these Data Logic Procedures as part of the overall SDO generation process and even fills in some of the validation logic that can be derived from looking at the database schema.
Figure 5–2 illustrates the whole “family” of objects that make up an SDO.
The following procedures make up an SDO:
- The full SDO procedure, which for dynamic SDOs is a completely Repository-based object.
- The client-side proxy version of the SDO procedure, which has the suffix
_clappended to its name, and has server-side logic compiled out. - The server-side logic procedure for the SDO, where validation logic requiring database access is written.
- A client-side proxy for the Logic Procedure, where the developer writes validation logic that can be executed without reference to the database.
The SDO and Logic Procedure proxy files are simple “wrapper” procedures that set a preprocessor value signaling that they execute on the client, and then include the full SDO procedure or Logic Procedure, so that the executable code exists in only one place. Again, for dynamic SDOs, the file does not exist on disk. It is a completely Repository-based object.
There is one more 4GL source file not shown, the include file containing the definition of the RowObject temp-table shared by all the other procedures. The Object Generator creates all of these for you.
The illustration in Figure 5–2 shows some examples of specially named internal procedures in the Data Logic Procedure, such as rowObjectValidate and preTransactionValidate, where particular types of validation logic go, depending on when it should execute, whether it can execute on the client or whether it must execute only on the server, and what kind of operation (Create, Write, or Delete) it applies to. The details of how to use these hooks are discussed in Chapter 10, " Building Basic Business Logic in a Progress Dynamics Application." This chapter discusses some examples of logic created for you by the Object Generator.